Generate tmux capability pages from port registries - #151

why: The optional-feature page is only useful while each feature keeps
its own requirement, the states use the contract's names and results
name ports instead of summarizing them as a ratio.

what:
- Require a table row for each optional feature with its tmux release
- Require a defining row for each of the five support states
- Reject ratios such as "5/8" or "five of eight" and require every port
  group in the port table

Verified: the check passes; dropping the Unverified row, changing the
named-buffer requirement to 3.3 and replacing a port group with a
"five of eight" count each make it fail on the matching case, and the
restored page passes.

why: A table typed into a guide drifts from the code it describes. The
capability pages must come from what each port's registry says, with
every API name tied to that port's reference.

what:
- Read capabilities.json from each port checkout, validate it, and
  resolve each API and error name through the port's API model
- Fail on a name the model lacks instead of rendering plain text
- Take release columns from tmux's own refs: final tags, release
  branches (3.7d), and the next-X.Y master names
- Run the check in test-all, with a fixture manifest that names a
  missing method to show the gate fails

why: Prose cells of different lengths made the old table jagged and hard
to scan. A map reads down a release and across a capability.

what:
- Lay the table out fixed, with equal-width data columns and a sticky
  capability column
- Show an icon per cell with a screen-reader label, and a legend of
  only the states the table uses
- Test equal widths, one labelled cell per column, and the legend;
  uneven column widths fail the first test

why: Readers need to know what a port does on their tmux release and
which methods that affects, from the port's own registry.

what:
- Add reference/capabilities: per port in a port build, a capability
  by tmux release matrix from the port's floor, plus workarounds
- In the root build, a capability by port map naming the release each
  port needs
- List each capability's API, refusal type and tmux commands as links
  to the reference
- Show only ports that publish a manifest, never a stand-in row

why: A reader on a tmux command's reference page should see which
libtmux ports gate that command and on which releases, the way MDN
shows browser support on an API page.

what:
- Render a ports matrix of every capability and workaround that names
  the command, linking each row to the capability map
- Add it to the page contents when a port gates the command
- Bind the capability helper in the glossary navigation test

why: The guide kept three hand-written tables of feature releases,
support states and per-port claims. They had already fallen behind the
ports and could not link to the methods involved.

what:
- Keep the explanation of optional features and what guards cover
- Drop the feature, state and per-port tables
- Link to the generated capability map
- Test that the guide holds no table of release requirements